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Abstract 

The Internet and its current information culture of preserving all kinds of data cause 
severe problems with privacy. Most of today's Internet users, especially teenagers, publish 
various kinds of sensitive information, yet without recognizing that revealing this informa- 
tion might be detrimental to their future life and career. Unflattering images that can be 
openly accessed now and in the future, e.g., by potential employers, constitute a particu- 
larly important such privacy concern. We have developed a novel, fast, and scalable system 
called X-pire! that allows users to set an expiration date for images in social networks (e.g., 
Facebook and Flickr) and on static websites, without requiring any form of additional in- 
teraction with these web pages. Once the expiration date is reached, the images become 
unavailable. Moreover, the publishing user can dynamically prolong or shorten the expi- 
ration dates of his images later, and even enforce instantaneous expiration. Rendering the 
approach possible for social networks crucially required us to develop a novel technique for 
embedding encrypted information within JPEG files in a way that survives JPEG compres- 
sion, even for highly optimized implementations of JPEG post-processing with their various 
idiosyncrasies as commonly used in such networks. We have implemented our system and 
conducted performance measurements to demonstrate its robustness and efficiency. 

1 Introduction 

The past decade has brought dramatic changes in the way we live and work. The wide ac- 
ceptance of social networks' free dissemination of personal information, the proliferation of 
networked devices that provide a means for such communication anytime, anywhere, and the 
resulting abundance of published information present significant opportunities. However, this 
information culture of acquiring and preserving all kinds of data also causes severe problems 
with privacy. Most of today's Internet users, especially teenagers, publish various kinds of sen- 
sitive information, yet without recognizing that revealing this information might be detrimental 
to their future life and career. Unflattering images - typically published within social networks 
- that can be openly accessed now and in the future, e.g., by potential employers, constitute 
a particularly important such privacy concern. This scenario is especially problematic since 
published information is cached by search engines, duplicated by mirrors and aggregators, and 
thus available essentially forever. 

In contrast to the current situation, archiving large amounts of data was traditionally ex- 
pensive and cumbersome, and a large-scale acquisition of sensitive information was close to 
impossible. In fact, it was the exception rather than the rule that personal information was 



explicitly archived; hence most such information became unavailable over time. (Moreover, even 
if photographs were properly stored, papers were properly filed, etc. these data were typically 
not accessible without explicit consent of the user.) The Internet with its current information 
culture and its infinite memory thus clashes with people's established expectation about the 
life-time of the information that they divulge to the public. This observation is substantiated 
by a work of Mayer-Schonberger [21J, who nicely compares modern electronic storage in the age 
of information technology with the traditional way in which paper documents are archived. His 
major observation was that retrieving information was traditionally often close to impossible 
after a certain period of time, and that this situation fuels the expectations of average users as 
far as expiration of data is concerned. In our current information culture, however, acquiring 
and preserving large amounts of data is quick and easy. 

The challenge is now to imitate the traditional expiration of data by developing a digital 
expiration date that lives up to the demands of the modern information culture - both in terms 
of user privacy and the seamless integration into common user activities in the Internet, such as 
publishing and consuming digital content. If published data becomes unavailable after a certain 
time, then this closely resembles the behavior of the paper-based world and thus brings the 
situation in-line with the prevailing user expectations. 

1.1 Our Contribution 

We have developed a novel, fast, and scalable system called X-pire! that allows users to set 
an expiration date for images in social networks (e.g., Facebook and Flickr) and on static 
websites, without requiring any form of additional interaction with these web pages. Once 
the expiration date is reached, the images become unavailable. Moreover, the publishing user 
can dynamically prolong or shorten the expiration dates of his images later, and even enforce 
instantaneous expiration. In the following, we describe our overall approach and highlight major 
design decisions. 

High-level view on the protocol. We implement the digital expiration date for images as 
follows: Images are encrypted by a symmetric key that is stored on a centralized keyserver. 
Access to the key is granted only until the expiration date set by the publisher during the 
encryption process. After encrypting an image, it is stored on a webserver to be viewed by the 
public. In order to view protected images, the key is retrieved from the keyserver and used 
to replace the encrypted image by its decrypted version. The keyserver additionally supports 
management functionality for already created keys; in particular this allows for prolonging 
and shortening the expiration date of keys. The latter can even be used to let images expire 
instantaneously. 

The major technical challenge: Dealing with JPEGs. Images are typically stored as 
JPEG files in static websites and in social networks. We thus have to embed encrypted images 
into JPEG files in a way that adheres to the JPEG format. Rendering this approach possible for 
social networks - where by far the largest number of sensitive images are published - is concep- 
tually challenging, since social networks typically re-encode images using JPEG compressions. 
Thus, simply uploading the encrypted data c would result in the publication of a re-encoded 
version c', in which the encryption would be fully destroyed. As a consequence, nobody would 
be able to decrypt the image anymore; it would expire instantaneously. To remedy this situa- 
tion, we have developed a novel technique for embedding encrypted information within JPEG 
files in a way that survives JPEG compression. Solving this problem was not only challeng- 
ing in theory. The implementations of JPEG used in the Internet are often highly optimized 
versions that do not strictly follow the JPEG standard and thus disregard accuracy in favor of 
performance (examples include rounding errors, lossy conversions, etc.). Our technique needs 
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no explicit support from existing webservers or social networks, and thus allows for a seamless 
integration into the existing infrastructure. 

Mitigating the data duplication problem. When protected images are published using 
our approach they can be viewed by the public until the expiration date is reached. Thus, an 
attacker will also be able to view these images in this time period (under the assumption that 
no additional protection mechanisms are in place, e.g., images are only visible to the friends 
of the user within the privacy settings of Facebook). The attacker is thus in principle able 
to store the keys needed for their decryption, and consequently to use them to decrypt these 
images even after their expiration date. Although this limitation is inherent to the problem, 
and thus equally applies to other approaches that strive for a digital expiration date (see the 
Related Work section below), we are the first to consider this case to the best of our knowledge. 
Using our centralized approach for the keyserver allows us to set up effective countermeasures to 
prevent an attacker from acquiring keys in a large-scale, automated manner. First, in order for 
users to retrieve a key, our approach requires them to send a hash of the encrypted image that 
they intend to view. Since computing this hash requires to download the encrypted image that 
is much larger than a key, it serves as convincing evidence that the corresponding band-width 
was consumed, thereby rendering a simply key-requesting attack much more costly. Second, we 
rate limit the retrieval of a large number of keys. Finally, our approach enables the publisher to 
additionally require users to solve Captchas before viewing the image (e.g. one for every photo 
album they are viewing). We stress that our protocol, and in particular its capability to deal 



with JPEGs, would work as well in a decentralized setting, see Section 1.2 on Related Work 



Efficient, scalable, one-click implementation. We have implemented our system and 
conducted performance measurements to demonstrate its efficiency. The software integrates 
seamlessly into the user's workflow when surfing on the Internet. The natural solution was to 
implement the client applications as browser plug-ins such that the existing workflow is not 
interrupted by starting an external application. In the viewing process no user interaction with 
the software is required; to publish an image, the user needs only to drag-and-drop this image 
into the application, and enter a desired expiration date. 



1.2 Related Work 

Meyer-Schonberger [2T] presents a nice introduction to the problems caused by the infinite 
memory of our information culture. He proposes to tag sensitive data with an expiration date 
and to require all servers handling such data to obey the expiration date. However, many 
servers would presumably not be interested in cooperating since their business model relies 
crucially on the collection and openly distribution of user data. Also a legal requirement forcing 
servers world-wide to obey to delete data seems out of reach in the near future. Moreover, it 
is technically difficult to audit whether the server actually deleted the data. Within the last 
years several attempts have ought to solve the problems that arose with the Internet's infinite 
memory. 

The first group of solutions adds an expiration date to data. It is implemented by encrypt- 
ing the data itself with a symmetric encryption key and restricting the access to these keys 
afterwards. We stress that none of these works is capable of dealing with scenarios where pub- 
lished data is subsequently manipulated, e.g., re-encoding of JPEGs as commonly done in social 
networks such as Facebook. Similarly, the threat of storing keys during validity has not been 
considered thus far. 

The first works that pursued this solution path aimed at securely deleting data including 
copies in archives. However, these works mainly target corporate use, and come with differ- 
ent requirements and design principles that are incompatible with our setting. In particular. 
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all servers are aware of the encrypted nature of the data, post-processing of the data is not 
supported, an adversary grabbing all keys while the data is available is not considered, and 
in some proposals the keyserver additionally aids in decrypting the data. The first such sys- 
tem we are aware of is [2], which provided the basic principles. A prominent system is the 
Ephemerizer \28\ [29] , which was later improved [23] . 

Vanish [H] constitutes a recent, promising approach along similar lines by storing shares of 
the keys in dynamic hash tables (DHTs), a data structure that underlies P2P-networks. The 
DHT will by design stop replicating the key after a certain time, so the key is basically lost after 
that and the encrypted data becomes unavailable. An attack against the proposed implementa- 
tion was recently published [37], using a Sybil attack on the DHT. An improved design of DHTs 
should fix this problem, at the cost of relying on a (slightly) more specialized design. We stress 
again that images and post-processing in general is not supported by this approach. Another 
difference is that we decided to ground our approach on a centralized keyserver solution, in 



order to mitigate the threat of key storage / data duplication, see Section 2.3 However, we 



emphasize that our proposed techniques for dealing with JPEG post-processing are applicable 
to their decentralized approach as well. Another current limitation of this approach is that the 
time after which data is not longer replicated by common implementations is often too short to 
be useful (8 hours for the proposed implementation). In case longer timeouts are needed, keys 
have to be kept "alive" by actively taking measures. 

The EphCom system |34j is very similar to Vanish, but uses a clever trick to store the 
keys in the cache of DNS servers, based on the presence of generated hostnames. Similar to 
Vanish, post-processing of protecting data and the threat of retrieving keys during validity is 
not considered, and for publishing data that expires at a specific time one needs to find a (large) 
number of domains that have the same TTL; their study shows that TTLs of more than 7 days 
are rather uncommon. 

The second group of solutions aims at securing privacy-sensitive content published in social 
networks, but based on a different assumption: The central difference is that these approaches 
store all data on an external, trusted server, which we believe does not scale reasonably well 
given the vast amount of images published every day. One example is FaceCloak [20], similar 
approaches include [19] and [9]. 

Our techniques for robustly embedding information within JPEG files furthermore resemble 
steganographic techniques to embed data into images and other data formats, e.g., [3]. Since 
these steganographic techniques additionally have to ensure that they embed information in an 
undetectable manner, existing solutions do not achieve sufficiently good data rates to robustly 
embed encryptions of high quality images into images that are accepted by social networks. We 
thus had to developed our own routine for embedding arbitrary data into JPEG images with a 
data rate that is sufficient for social networks. 



1.3 Paper Outline 

Section [2] provides a general overview of our approach. The full technical details of the system 
as well as necessary background information are provided in Section [3] and Section [4] Our imple- 
mentation is described in Section [5] which is followed by the results of an experimental analysis 
of the implementation in Section [6j We provide a discussion on X-pire! and its functionality in 
Section [7j before we conclude and present future work in Section [8) 
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Figure 1: Schematic overview of our approach 



2 Schematic Overview of X-pire! 

We have developed a novel, fast, and scalable system that allows users to set an expiration 
date for images in social networks (e.g., Facebook and Flickr) and on static websites, without 
requiring any form of additional interaction with these web pages. The expiration date is chosen 
by the user who publishes the data. Alternatively, users can decide to specify an undefined 
expiration date at the time of publishing their images, and instantiate / alter it later. Once the 
expiration date is reached, the images become unaccessible. 



2.1 Protocol Overview 

A high-level overview of the protocol and the involved participants is given in Figure [T} The 
involved participants of the protocol are the content publisher V, the content server C (which 
is often a social network), and the viewer V. We add a specialized keyserver K, to the setup, 
who is trusted not to hand out keys after their expiration date has been reached. 

Our approach distinguishes three phases: 1) the content publishing phase, i.e., adding the ex- 
piration date and storing the resulting images, 2) the viewing phase, i.e., visiting the correspond- 
ing websites containing these images, and 3) the update phase, i.e., shortening or prolonging the 
expiration date of published images. 



2.1.1 Publishing Phase 

When publishing an image d, the publisher V first contacts the keyserver fC with the request 
for a key. The keyserver creates a new key k and returns it to the publisher. V now encrypts 
the image c ^ Ek{d), hashes this ciphertext hash ^ H{c), and sends the hash hash and the 
expiration date expdate back to the keyserver, which adds the hash and the expiration date to 
the respective entry. /C finishes the key creation by sending the key ID idk back to the publisher. 



The encrypted data c is embedded into a valid JPEG image (see Section 2.2) and stored on the 
content server C. 

The reason to store keys rather than encrypted images is that keys are much easier to 
handle due to their small size. Thus users can utilize the large storage capacity offered by the 
websites/social networks, and avoid turning the keyserver into a performance bottleneck. 



2.1.2 Viewing Phase 

When a user wants to view an encrypted image c on a website, the user sends its hash H{c) and 
the key identifier idk of the key k retrieved from the image to the keyserver. The keyserver checks 
that the expiration date has not yet been reached, checks the correctness of the additional data, 
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and (if all these checks passed successfully) sends back the key k. If the key gets delivered, i.e., 
the expiration date of the key k has not yet been reached, the image c decrypted, and the user 
is able to view the image d. The reason to send the hash H{c) is to provide convincing evidence 
that the corresponding image was really downloaded. This renders a simply key-requesting 
attack much more costly in terms of band-width consumption. 

2.1.3 Update Phase 

We provide a comprehensive key-management interface that allows users to later review all 
previously generated keys along with a description of the corresponding images. This enables 
the publisher to update existing expiration dates. In particular, a publisher can prolong or 
shorten existing expiration dates, and even enforce instantaneous expiration of published images 
if desired. We describe the protocol in more detail in Section [3| 

2.2 Embedding encryptions to JPEG 

Our approach requires the encryption data c to be stored on the content-server C. This task is 
inherently more difficult for images, since social networks such as Facebook and Flickr scale and 
re-encode images before storing them (in contrast to scenarios where data is not subsequently 
manipulated [HI [3l]). First, this means that an upper bound on file size and image dimensions 
is enforced upon uploaded images. Second, and more important, the image is re-encoded using 
JPEG compression. Thus, simply uploading the encrypted data c would result in the publication 
of a re-encoded version c', in which the encryption would be fully destroyed. As a consequence, 
nobody would be able to decrypt the image anymore; it would expire instantaneously. Therefore, 
a robust embedding is required. Common steganographic techniques do not achieve sufficiently 
good data rates to robustly embed high quality images in images facing such constraints. We 
have developed a novel, robust embedding of arbitrary data into JPEG images that achieves 
sufficiently good data rates such that encrypted images can be embedded into JPEG images 
that are accepted by social networks. We describe this embedding in detail in Section [4} 

2.3 On the centralized approach 

Decentralized solutions are often considered superior to centralized ones, as they typically offer 
better performance and scalability. In the situation we are facing in this paper, however, we be- 
lieve that a centralized approach has advantages that outweight the benefits of decentralization, 
as described in detail below. We hence decided to ground X-pire! on a centralized keyserver, 
but we stress that our technique for dealing with post-processing of images, which arguably 
constitutes our main contribution, can be similarly incorporated to decentralized systems like 
Vanish [8]. 

• Using a centralized keyserver allows us to increase the costs for an attacker to retrieve 
keys by requesting users to provide convincing evidence that they actually know the data 
for which they are requesting the key for. This is ensured by storing and matching the 
hash of the encrypted data. 

• Using a central keyserver we can limit the rate of key requests possible from single IP- 
addresses and IP-ranges. 

• If desired, our approach enables the publisher to additionally require users to solve 
Captchas before viewing the image (e.g. one for every photo album they are viewing). 
This can be easily realized by having the centralized keyserver generate the Captcha, 
and it effectively raises the bar that a large number of keys will be downloaded using 
automated crawling. 
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We describe more details about the measures taken against collecting keys in Section [3j 

Besides these security issues, a central keyserver also provides more flexibility in the ex- 
piration dates than decentralized solution attempts. In addition to providing faster access, a 
centralized approach exceeds a peer-to-peer setting in terms of scalability in this scenario, where 
only short keys are stored. Moreover, it is arguably more privacy-friendly to trust a dedicated 
keyserver rather than trusting the social networks, whose business model relies crucially on 
the collection and openly distribution of user data. A centralized keyserver does not have a 
business incentive to act unexpectedly, but rather would lose its credibility if it becomes public 
that the server acts inappropriately with these keys. We currently provide our own dedicated 
keyserver, but we additionally released the keyserver application such that other trustworthy 
authorities or individuals can set up a keyserver as well. In the case that a user is not willing 
to trust any of these keyservers, he can still set up a personal keyserver himself to avoid such 
trust dependencies. 

2.4 Implementation 

We provide a complete working implementation of the protocol. The Browser extensions are 
implemented as a Firefox plug-in that is functional on all major platforms (Windows, Linux, 
Mac). The image embedding part as described above is currently implemented to work on 
Facebook j3j, Flickr [6], and wer-kennt-wen |36j (a famous German social network). We do not 
expect major problems in adding support for further social networks, since all social networks 
we are aware of rely on common techniques for JPEG compression based on the lib JPEG. To 
store an image, the plug-in prompts for the files, and performs all operations described above. 
It stores the processed files in a temporary directory, from where they can be uploaded by any 
upload-mechanism that is offered by the social network. 

When users are visiting a website, the plug-in searches for protected images, automatically 
retrieves the required keys from the keyserver, and displays the decrypted image inline on the 
page without any further user interaction. If the plug-in is not installed, these images show a 
brief statement that the required plug-in is missing, along with a link where the plug-in can be 
downloaded. A detailed description of the process of detecting and displaying protected images 
can be found in Section [H 

3 Detailed Protocol Description 

In this section, we give a detailed description of the protocol that underlies our approach. The 
protocol considers three participants: the data publisher the data viewer V, and the keyserver 
/Cj^ Consequently, our software is split into three applications: the X-pire!-Publisher, the X- 
pire!-Viewer, and the X-pire!-Keyserver. The X-pire!-Publisher establishes a communication 
channel between the publisher and the keyserver, and adds an expiration date to the desired 
images before they are uploaded to, e.g., Facebook, in the usual manner. The X-pire!-Viewer 
permits the viewers to display these uploaded images, provided that the respective expiration 
dates have not yet been reached. In order to display these images, the X-pire!-Viewer establishes 
a communication channel between the viewer and the keyserver. Finally, the X-pire!-Keyserver 
creates, stores, and hands out the necessary keys as described above, and it allows publishers 
to subsequently update the expiration dates of their keys. 

^We sometimes additionally speak about a content server C: an arbitrary server of one of the supported social 
networks that takes care of storing and providing the content that is created by our protocol. However, this 
entity C is not required to take part in the actual protocol. 
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In the following, we describe these communication protocols in detail. We distinguish three 
phases: the content publishing phase, the viewing phase, and the update phase. 



3.1 Publishing Phase 

In the publishing phase, the publisher requests a key by invoking a key creation process on the 
keyserver [CreateKey) and by providing his account information cred. The keyserver generates 
the key k and sends it along with a session ID ids back to the publisher (see below for how ids 
is used). The publisher receives the key and encrypts the image d that he wants to upload with 
k as 

c ^ Ek{d). 

For encryption we use the Advanced Encryption Standard (AES) [25] with a key length of 256 
bits and Cipherblock Chaining Mode (CBC) p2] . 

The ciphertext c needs to be embedded into another image file container to obtain a valid 



image file emh (details of the embedding are shown in Section 3.4): 

emh Embed(contamer, c) 

Without embedding c into emh it would not be possible to upload it as an image to a social 
network since c constitutes a ciphertext and hence does not fit the format of an image file. 

We stress that developing a suitable embedding is difficult, since social networks commonly 
apply image post-processing techniques, and thus to be suitable, an embedding must be resistant 
to JPEG recompression. 

After encrypting the image d to the ciphertext c, the publisher replies by sending the hash 
of the newly encrypted image c back to the keyserver. The hashes are computed by applying 
the SHA256 [26] hash function H to the encrypted images: 

hash ^ H{c). 

The hashes are sent to the keyserver by invoking AddHashes on the server side using the 
previously received session ID idg and the following additional payload: 

1. expdate: the expiration date chosen by the user, 

2. hash: the hash of c, and 

3. description: an identifier to describe (collections of) images; it has to be explicitly set by 
the user. 

In order to complete the publishing phase, the keyserver stores the key k, the expiration 
date expdate, the description description and the hash hash to its database thereby creating 
the unique key ID idk, which is also stored. Finally, it acknowledges the key creation process 
by returning idk of the previously created key k to the publisher. 

The hash is required because it serves as convincing evidence that the whole data has been 
downloaded before the key was requested. Finally, the identifier description plays two important 
roles in our protocol. 

First, it is used for a subsequent key management. Together with the creation date and the 
expiration date, the description yields a unique identifier that later enables users to identify 
specific encryption keys, e.g., for prolonging or shortening the expiration date. In particular, by 
changing the expiration date it is possible to let images expire instantaneously if desired. Fur- 
thermore, all images prepared in the same step using one description share the same expiration 
date. 

Second, it allows for grouping images, and for a controlled use of Captchas. If several images 
are prepared for uploading at the same time using the same description, all images are encrypted 
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with the same key. This allows for syntactically grouping images, and for a simpler decryption 
functionality, where only one key needs to be requested for one set of images. Moreover, it 
allows for a controlled usages of Captchas: The publisher can decide to require Captchas for 
additional security. In this case, every viewer will have to solve a Captcha before the correct 
image is displayed. Images with the same description will receive one joint Captcha. The idea 
behind a set of images using the same description and therefore having the same encryption 
key is that, e.g., whole albums can be viewed after providing the solution to a single Captcha. 
From a security perspective, disabling Captchas, or only asking for one Captcha per collection 
of images, reduces the security and increases the vulnerability to automated crawling attacks. 
However, for reasons of efficiency and seamless integration, we prefer to keep the number of 
Captchas low. 

3.2 Viewing phase 

After the image emb with the embedded ciphertext c has been created, it can be uploaded to 
the target web site, e.g., to Facebook. From that time onward, it can be viewed using the 
viewer plug-in by any eligible user that has access to the (encrypted) image on Facebook. The 
viewer is required to decrypt the prepared images and to correctly display them, provided that 
they have not yet reached their expiration date. Without the viewer, only the container images 
providing a link to the viewer application are shown; the actual image stays encrypted. 

When a user enters the website of one of the supported social networks with a browser 
that has the viewer application installed, the viewer starts to search for encrypted images. If 
it detects an encrypted image, it starts the decryption process. The viewer extracts the key 
identifier id^ as well as the address of the server storing the key (keyserver) and computes the 
SHA256-hash of the encrypted image. This information is used to invoke the GetKey process at 
the keyserver. The server performs a key lookup, and distinguishes two cases: If the expiration 
date has already been reached, it returns an error code indicating the expiry; if the expiration 
date has not yet been reached, the server checks whether the settings of the key require the 
viewer to solve a Captcha to sec the decrypted picture. 

If no Captcha is required, the server sends the requested key along with ids back to the 
viewer. The viewer uses the retrieved key to decrypt the detected image. Afterwards, the 
detected image is locally replaced by the decrypted one. 

If a Captcha is required, the server sends a CAPTCHA_REQUIRED request to the viewer. 
The viewer requests a challenge from the Captcha service using the public key of the keyserver, 
the user solves this challenge and sends it together with the solution to the keyserver. The 
keyserver uses its private key and verifies together with the Captcha service whether the solution 
was correct. If a wrong solution for the Captcha is sent to the keyserver, the server notifies the 
viewer that the solution was wrong and invalidates the challenge during its verification with the 
Captcha service. The viewer then decides whether to give up or try again by requesting a new 
Captcha. If the correct solution is provided, the server sends the requested key along with ids to 
the viewer as described above. Adding Captchas results in additional communication between 
the Captcha service and the viewer as well as between the Captcha service and the keyserver. 

3.3 Update Phase 

Our protocol allows users to manage and update the keys that they have already created with 
the keyserver. The keyserver offers a web interface that provides all necessary functionality to 

identify already existing keys using a unique identifier comprised of the description, the create 
date, and the expiration date, and to modify the current settings. The main functionality of 
the key management is to allow the publisher to prolong or shorten the expiration dates for 
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keys that have aheady been created. In particular, it allows a user to enforce an instantaneous 
expiration of his images. 



3.4 The Embedding 

The main goal of our approach is to find a method for adding an expiration date to an image that 
is subsequently hosted on an existing web site. Because encrypting images and later restricting 
the key access while retaining a valid image files is the only possibility to solve this problem, we 
must embed all data needed for the decryption into the image file itself. To publish images to 
the internet users can either provide them inside of plain HTML-pages by the {img)-tag (users 
need to have access to the source of these pages in order to add images) or provide them within 
special Internet services like social networks (e.g. Facebook or Flickr) where users provide their 
images as image files to an upload-interface. To the best of our knowledge, although social 
networks support several image formats for uploading, all existing social networks store the 
final image as a JPEG file. Therefore, our approach provides a solution for JPEG files. Since 
the expiration date is implemented by encrypting data and restricting the access to the keys 
needed for decryption to the time until the expiration date is reached, all information needed 
to retrieve the key for decrypting the image needs to be stored inside of the JPEG file: 

• the keyserver address keyserver to place the query, 

• the key ID idj. to identify the needed key, 

• the version ID version, and 

• the encrypted image c to compute the hash hash and to decrypt the image itself later. 
We have to decide where in a valid JPEG file the data can be embedded, without causing 

the file to be rejected by upload-interfaces. Inside of the {img)-tag, HTML expects one of the 
supported image formats (e.g. JPEG, PNG, GIF). If a JPEG file is encrypted by standard 
methods, the outcome is a ciphertext and not an image file. Therefore, it is necessary to embed 
the ciphertext into another "container" -JPEG such that the outcome is still a valid JPEG. In 
general, one can think of two approaches to achieve this: one either stores the encryption within 
a header field, or inside the actual image data. We will discuss both approaches in detail in 



Section 4.2 after we have introduced relevant background information on JPEG in Section 4.1 
but we anticipate the major lessons learned and results here: Embedding the encryption in 
the header information is significantly more efficient and easier to handle; however, virtually 
all social networks remove all header information for uploaded images, rendering this approach 
completely useless for those sites. The alternative - embedding within the actual image data 
- is significantly more challenging because our embedded encryption must survive the JPEG 
recompression that these sites apply to the image data. We developed a suitable such embedding 
that renders the approach possible and practical for social networks. 



4 Surviving JPEG Compression 

In this section we first provide general background information about the JPEG standard. 
Afterwards we discuss in detail the two embedding approaches mentioned above. 

4.1 Details on JPEG 

The JPEG standard was developed by the Joint Photographic Experts Group in 1992 [T6] and 
is the current de-facto standard for compressing images in the Internet. A JPEG image is most 
commonly stored in a file according to the JPEG File Interchange Format (JFIF) [10]. This 
standard defines the complete structure of the file and describes how and where to store all the 
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information (e.g. Huffman tables, quantization tables) needed to later decode the image again. 
Usually, when people refer to JPEG files, they are actually referring to JFIF files. 

We focus on the Baseline DCT (BDCT) mode of JPEG in our description, since it is the 
most widely used mode in the Internet, and also the mode used in the social networks currently 
supported by X-pire!. In the following, we describe the individual steps of the JPEG encoding; 
an overview is given in Figure [2j 

4.1.1 RGB to YCbCr Conversion 

The starting point for creating a BDCT image is an RGB image |27] consisting of x by y 
pixels. RGB images store for every pixel {x, y) the red, green and blue color components. All 
three color channels together are converted to the YCbCr p7] color model that consists of the 
luminance channel Y and the two chrominance channels Cb and Cr. The luminance channel Y 
provides information about the brightness, whereas the two chrominance channels Cb and Cr 
provide color information. The conversion between the two color models is not necessarily lossy. 
However, divisions often introduce rounding errors when real valued results are converted back 
to integer values, and both the input RGB-values and the resulting YCbCr- values are typically 
integer values. 

As an optional step, the color model conversion might be followed by subsampling. Subsam- 
pling was not included in the original JPEG standard, but was later published as an extension 
|17| . Subsampling reduces the size of a channel by downsampling it in a horizontal and/or ver- 
tical direction. Subsampling is typically applied only to the chroma channels; we hence assume 
here that the luminance channel is left unchanged. A common case for highly compressed JPEG 
images is a 2x2 chroma subsampling where only half of the information in the horizontal and 
vertical directions is kept. Thus, if we have an image size of x by y pixels (which is also the 
size of the luminance channel), the chroma channels each have only x/2 by y/2 pixels, and thus 
they are only 1/4 of their original size. We refer to [Til |271 E] for more detailed information 
about subsampling. 

After the color model conversion and the optional subsampling, the image is level-shifted by 
subtracting 128 from all values. This produces a signed result with smaller values. Next, the 
image is split up into blocks. Each block consists of 8 by 8 pixels (default size for BDCT) and 
is extracted from the image as shown in Figure [7| in Appendix |Aj The image block's values are 
called the DC-component (the value at position (0,0)) and AC-components (all other values). 

4.1.2 Discrete Cosine Transform 

The extracted blocks are used as input for a discrete cosine transform (DCT). The DCT function 
gets as input an image block with integer values and outputs a block with real values. 
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4.1.3 Quantization 

Quantization plays a crucial role for the compression of a JPEG image and is performed by 
dividing an image block by the so-called quantization table. A quantization table consists 
of 64 values, and each value corresponds to one value inside an image block (see Figure [s] in 
Appendix[A]for a quantization table used by Facebook). The division is done by dividing a value 
from the image by its corresponding value from the quantization table and rounding the result. 
The values of the quantization table define the compression rate and can be user-defined. Every 
single value has to be in the interval from 1 to 255. If all values inside the quantization table 
are 1, no compression is in place; the higher the values, the higher the compression rate. The 
quantization tables are stored inside of the JFIF-file and used again later during the decoding 
of the image. 

4.1.4 Huffman Encoding 

Finally, the DC coefficients (the values at position (0, 0) of each block) are difference-encoded, a 
zig-zag reordering is applied, and the result is Huffman-encoded. The difference encoding works 
as follows: every DC coefficient is replaced by the result of substracting the previous blocks' 
DC coefficient from the current DC coefficient. Although Huffman encoding optimizes the final 
image size, the encoding is lossless, similarly for the difference encoding and the reordering. 
The information needed for a later Huffman decoding is stored inside of the so-called Huffman 
tables; they differ for the DC and AC components and for the luminance and chrominance 
channels. All four tables are stored analogously to the quantization tables, i.e., they are stored 
inside of JFIF files for a later decoding. 

In order to decode a JPEG image, the procedure is simply reversed. Starting with the JPEG 
file, a Huffman decoding is applied first. Then the reordering is removed which is followed by 
undoing the difference encoding. A dequantization is then applied using the same quantization 
matrices that were used during the encoding. After the inverse discrete cosine transform has 
been applied, the values are shifted back (undoing the level shifts from the encoding) and finally 
the YCbCr color channels are converted to the RGB colorspace. 

4.2 Robustly embedding encryption into JPEG 

We have pursued two main approaches for including the ciphertext in the JPEG image. The 
straightforward way is to embed the encrypted image into a special header field of a JFIF file; 
the alternative approach is to embed the encryption into the actual image data of a JFIF file. 

Whenever the websites that host the image retain header information, placing the encryption 
in the header is clearly the best method in terms of performance. However, this approach is not 
feasible for common social networks, since they immediately remove all header fields contained 
in images. For social networks, we thus have to embed the ciphertext in the image data of the 
JFIF file. However, when images are uploaded to a website via a web- interface, such as for social 
networks, they are often recompressed. This recompression is highly problematic for us: By 
the cryptographic properties of secure encryption schemes, we will only be able to decrypt the 
encrypted image if it is recovered with 100% accuracy (bitwise). Otherwise the decryption will 
fail, or provide non-sensical results. In order to achieve the goal of 100% accuracy, we have to 
embed the encryption into a JFIF file so that the embedding survives the JPEG recompression. 
In the following, we present and discuss both approaches. 
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4.2.1 Embedding encryption inside of header fields 

The JPEG standard supports comments inside the image header, which can be also used for 
storing the encrypted image. The length of each comment field is limited, but the number of 
comment fields inside the header is unconstrained. 

This solution solves the problem for web applications where images are provided for viewing 
without any further modifications. The classic example is a static website where images are 
stored on the webserver and linked using the {img)-tag of the HTML standard. We have 
implemented the embedding into headers fields as one of the supported solutions for these 
classic websites. For these websites, placing the encryption in the header is clearly the best 
method in terms of performance. 

4.2.2 Embedding encryption inside of image data 

When images are uploaded to social networks they are often scaled and recompressed. The 
problem of scaling is solved in our approach by providing encrypted images inside a container 
image that exactly matches the sizes expected by social networks so that rescaling does not 
occur. We describe in the following how we address the problem of image recompression. 

Embedding an encrypted image into the image data in a way that it survives JPEG recom- 
pression turned out to be a challenging task. For the sake of exposition we first describe an 
intuitive approach for embedding the encrypted image inside of image data that we initially 
pursued, and then described where it fails. After that, we explain the modifications we had to 
make to actually solve the problem. 

The first approach we pursued when we recognized that social networks decompress JPEG 
images and then compress them again with their own settings (compression ratio, header fields 
etc.), was to compute a preimage for the JPEG image that we wanted to upload to the social 
network, i.e., the image that contains the encryption. The underlying idea was to embed the 
data into a container image and to take this container image with the embedded data as the 
starting point. Let us call it Image. Knowing that Image is exactly the image we want to have 
on the website later, it is necessary to go through the compression steps done by the social 
network in the opposite direction. We want to know precisely which Image' we have to provide 
for the upload such that after the compression the outcome on the website is exactly Image. To 
achieve this, all functions applied during the compression have to be inverted step by step. After 
we compute Image', we must provide an Image" without any JPEG compression to the social 
network, such that decoding it results exactly in the computed preimage Image'. However, 
going this direction turned out to be infeasible because this approach includes inverting the 
Huffman-encoding without having the Huffman-tables. Without the tables, the information 
needed to decode the image is not available and therefore the decoding can only by done by 
brute force. 

Our second approach was to modify our input image such that the compression step using 
the quantization table cancels out. This would provide us with a resulting image in which we 
can control the content of the luminance channel. To achieve a canceling out of the quantization, 
its inverse needs to be applied beforehand. Therefore, we modify the quantization table used 
for encoding the JPEG image that is initially uploaded to the social network. This causes the 
dequantization done during the image decoding inside of the upload routine to exactly apply 
the inverse of the quantization done later during the encoding. Let A be the quantization table 
used by the social network, then we can use a quantization table A' for the initial image that 
is achieved by a point-wise division with A as follows: 
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This solves the problem of embedding encryptions into JPEG images such that they survive 
the JPEG recompression, at least in theory: This approach worked perfectly well with our 
implementation, which strictly follows the JPEG standard. 

4.3 Dealing with libJPEG and its idiosyncrasies — how to achieve robustness 
in practice 

However, when using the libJPEG implementatioi:[^ this approach broke down completely. The 
computations done in libJPEG are highly optimized and introduce, for example, rounding errors 
that our mathematical accurate computations according to the JPEG standard did not have. In 
general, a small amount of loss is not really a problem for images since users do not detect such 
small differences, but in our case we need enough accuracy to reconstruct the embedded data 
100% correctly to perform the subsequent decryption. In this setting our reconstruction rate 
was only 10%, which made it impossible to amplify this approach using error-correcting codes. 
Since the social networks our software targets use libJPEG, the limited accuracy of libJPEG 
also rendered our second approach infeasible. 

libJPEG-Details. Before we analyze how to circumvent the accuracy problems introduced by 
libJPEG, we will have a closer look at what libJPEG does. The library is entirely implemented 
in G. A typical workflow for an application using libJPEG for image manipulation is as follows: 
let libJPEG decompress the source image, define parameters for the resulting image, and let 
libJPEG compress the image again using the defined parameters. Performing only a specific 
operation of the JPEG compression process, e.g., the quantization in Figure [2| by just calling 
a "quantize" method is not possible, as the library combines steps of the process for optimized 
performance. Moreover, operations like scaling are combined with the DCT computation, at 
some places precision is sacrificed in favor of speed, and many special cases of the same operation 
are handled by individual functions. As a result, using libJPEG as intended, i.e., to perform a 
whole image compression process, is easy, whereas performing JPEG compression steps one by 
one as shown in Figure [2] is close to impossible. 

All social networks in the Internet we are aware of either use libJPEG directly, or use image 
manipulation programs like GD [7J, and ImageMagick [13j that rely on libJPEG. To the best of 
our knowledge, all of them follow the intended workflow. They just call the library to perform 
the intended operations without doing any in-depth manipulation. 

For our approach, however, it is crucial that we can interfere with the JPEG compression 
and decompression processes. This requires an in-depth understanding of the libJPEG functions 
and increases the work needed to embed the necessary functionality. 

■^libJPEG is a popular and widely used implementation of the JPEG standard, written and maintained by 
the Independent JPEG Group [T^. All social networks we are aware of use libJPEG directly, or use image 
manipulation programs that rely on libJPEG. 
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Dealing with libJPEG. Since libJPEG's inaccuracy rendered our mathematically-correct 
approach infeasible, it was necessary to have an approach for embedding data that survives 
the compression done by the quantization step. Since the quantization tables used for the 
compression are publicly known - usually they do not change for one service and can be extracted 
from every JPEG image we must try to embed data such that applying the division inside 
the quantization does not destroy the embedded information. 

If we have a look at the quantization table used for example by Facebook, we can see that 
the highest value used in the luminance table is 36. The values inside of one image block that 
are divided by the quantization values are 8-bit unsigned integers. If we look at the binary 
representation of such a value, a division by 36 does not destroy the two most significant bits. 
Therefore, we embed two bits as the two most significant bits in every value of every block 
inside of the luminance channel. In order to improve the results and to gain more stability, we 
also always set the fifth bit to one and bits zero to four to zero. This protects bits six and seven 
from being affected by rounding errors, as it prevents even significant deviations in the lower 
bits from reaching the upper bits. 

Embedding two bits works as long as the divisor needs at most six bits in binary represen- 
tation. For all social networks of which we are aware, the maximal divisor has at most six bits. 
In general, when quantization tables with higher values are used, it might only be possible to 
embed one bit or even none. If smaller values are used, it would be possible to embed more 
than two bits per byte. For the future, one could use the knowledge of the quantization tables 
to design an approach that dynamically optimizes the number of bits to be embedded per co- 
efficient. With the current approach of embedding two bits per byte we have an upper bound 
on the amount of bits we can embed: 1/4 of the original luminance data, two bits per pixel of 
the luminance channel instead of eight. If subsampling is used for the luminance channel, the 
maximum amount that can be embedded decreases accordingly. However, the amount of infor- 
mation that we can embed using our technique is more than sufficient for embedding encrypted 
images into cover images that are permitted by the social networks, and thus for realizing the 
desired expiration date. The white boxes in Figure [2] show at which point of the JPEG encoding 
and decoding processes the ciphertext bits are embedded and extracted. 

Note that although we have eliminated most loss by embedding the encrypted data only in 
the two most significant bits, a small amount of loss can still occur, e.g., because of internal 
rounding mistakes. Thus, it is necessary to apply an error-correction method. The current 
approach uses Reed-Solomon codes |32] with a configuration {N,K) of (255,191). This means 
one error correction unit consists of 255 bytes, 191 bytes data and 64 bytes of additional infor- 
mation. The introduced overhead reduces the real space for embedding information to 3/16 of 
the original payload since the 64 parity bytes per block have to be embedded as well. Using 
this configuration it is possible to recover the correct ciphertext even if up to 12.5% of each 
error correction unit is lostj^ The complete workfiow starting with embedding bits until the 
final extraction of the encrypted image is shown in Figure [3| 

We recompress our images before we embed them with quality settings similar to the ones 
used in social networks. Consequently, although we embed data only into the two most significat 
bits per byte, our method can be applied to achieve essentially the same image quality in 
practice as images that have been uploaded directly to social networks like Facebook. We refer 
to Appendix [B] for bounds on possible image sizes and illustrative images. 

^We never encountered more than 5% incorrect bits in our experiments with this approach, i.e., a significantly 
weaker error-correcting code with a smaller overhead would have been sufficient. However, we decided to deploy 
a stronger code to catch unexpectedly bad results that might arise. For the same reason, we currently only embed 
two bits in every value of every block, even though our experiments indicated that more bits could have been 
embedded in most cases. 
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5 Implementation 



We have implemented the pubhsher and the viewer as Mozilla Firefox extensions, so that the 
user can prepare protected images when browsing his social network site without switching 
programs. The extraction of protected images is completely automated and opaque to the user. 

Both the publisher and the viewer application share a core library that provides encryption, 
JPEG manipulation, and error correction, as well as a high-level communication functionality. 
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The core library used by both applications is responsible for the actual handling of pro- 
tected images, i.e., modifying JPEGs, encryption and decryption, computing hashes, and error 
correction. It is implemented in C and C++. The reason for the separation of core library and 
client applications is the availability of fast and well-tested libraries for cryptography, JPEG 
manipulation, and error-correcting codes in C, as well as the lack thereof in Javascript. How- 
ever, Javascript is much better suited for high-level server communication than C or C++ and 
is therefore used for the communication task. In particular, we rely on OpenSSL for hashes and 
encryption, libJPEG for JPEG manipulation, and our own implementation of Reed-Solomon 
codes for error correction. For embedding data into JPEGs for social networks, we extended 
libJPEG with a small module that is called during the DCT and the IDCT computation. We 
combined our code for embedding data into the JPEG header for images on static websites 
and the modified version of libJPEG into a C++ library that provides high-level functions for 
generating and reading of protected images to our applications. 

Our code requires functions to be called from C libraries directly. Although Gecko engine 
2 (the engine underlying Firefox 4) will allow this directly, the current version of the Gecko 
engine does not. As a result, we had to add an XPCOM component to our extension. Using 
the XPCOM framework we are able to call routines from native code in the extension as we 
would do it with Javascript or XUL functions. Thus, the final step in our implementation was 
to extend our library to be compatible with XPCOM and to add the result as a component to 
our Firefox extension. 

The image lookup itself is performed by handler functions in the viewer which check websites 
for protected images. These functions check every (img) -element on a whitelisted website (we 
use a social network whitelist to reduce the overhead introduced by our technique, see Section^ 
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being a protected image, whether it is staticahy present or dynamically inserted using Javascript. 
The latter is the case for most images on social networks, as their websites are usually created 
dynamically. If a protected image is found, the viewer decrypts it and replaces the {img)-tag 
containing the protected image locally with a new one containing the whole decrypted image 
data in base64 encoded form. Although the use of base64 encoded image data in {img)-tags 
is not part of the HTML standard yet, it is considered as good as standard and nearly all 
browsers support this feature. For the user, this replacement is seamless and does not require 
any interaction. 

Besides the two client applications, our approach further contains the keyserver. It is imple- 
mented in Scala [33], a programming language targeting at the Java Virtual Machine (JVM) ^35j. 
In addition, we use the Lift-framework [18j for web application development and PostgreSQL 
|30| . The latter is used to store the keys sent by the users. All communication between the 
X-pire! extension and the keyserver is implemented using XMLHTTPRequests in Javascript. 
Further, data is transfered using HTTPS, thus ensuring secure and reliable communication. 

To prevent attackers from collecting keys, our implementation permits the use of Captchas 
as described before. We use Google reCAPTCHA [31j as a concrete implementation, re- 
CAPTCHAs are based on text extracted from old books which could not be recognized by 
OCR tools. The whole communication with the Google servers is also secured by HTTPS. 

6 Experimental Analysis 

Introducing an extra step into the workflow of uploading and viewing images on the Internet also 
introduces some extra time needed to complete the calculations. We performed several client- 
side benchmarks to evaluate the time needed to encrypt and embed images and to evaluate 
the overhead that is incurred by the X-pire! plug-in while viewing websites. In addition, we 
compared the two methods of embedding an encrypted image into a container JPEG: embedding 
the payload into the header field and embedding the payload into the luminance channel. 

The benchmarks were run on a notebook with 4GB RAM and a 2.2 GHz Intel Core 2 Duo 
CPU using Mac OS X 10.6.4 as the operating system. 

To evaluate the time needed for encryption and embedding, we performed the encryption 
and embedding computations 50 times for different numbers of images. The actual time needed 
for a given number of images was evaluated as the average over all measurements for a particular 
number of images. The results are depicted in Figure [ij As expected, embedding data into the 
header field is much faster than the luminance channel method. Both methods scale linearly. 

To measure the overhead when viewing websites, we created static HTML-pages rather 
than using existing websites. The reason for this is that a single real world page like Facebook 
consists of several elements which are provided by different servers. Moreover, with each reload, 
the page looks different and consists of different elements. Further, if only one server that 
contributes elements to a website such as Facebook is not responding, incorrect timing results 
will be obtained. 

Again, we benchmarked with different numbers of pictures and 50 runs per series. Figure 
[5] and Figure [6] show the overhead results. On a web page which contains no images that are 
recognized by the viewer, the overhead of using the plug-in in comparison to not using the plug- 
in is not measurable (Figure [s]). On websites with protected images, the luminance channel 
method is again slower than the header field method (Figure [6]). Fully decrypting images using 
the header field method is as fast as checking whether a possible candidate is really a protected 
image using the luminance channel method (Figure [g]). Neither the header storing method, nor 
the bit embedding method scales linearly; we expect that this happens due to the way Firefox 
implements Javascript DOM handlers and events \23\ . 
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We also analyzed how the centralized server approach scales in terms of number of active 
sessions and number of simultaneous requests. The machine used as a server was an off-the-shelf 
office computer with 4GB RAM and an Intel Core 13 540 CPU with two cores and multithreading 
enabled. We used Ubuntu 10.04 Server Edition as the operating system, Jetty 6 [l5] as the Java 
webserver, and ApacheBench [1] as the benchmark tool. We assigned a maximum of 2GB heap 
space to the JVM running the Jetty instance. Since Jetty does not provide a way to display the 
number of active sessions, we can only give rough upper bounds derived from the total number 
of session creating requests. Using this method, we were able to create about 820,000 sessions 
which resulted in nearly 2GB of memory usage. At this point, the JVM garbage collector 
slowed the system down to the point where the server stopped responding to our requests. So 
even when using off-the-shelf equipment, our keyserver is able to handle a reasonable number 
of users. 

In a different benchmark evaluating the server's scalability in terms of CPU load, we were 
able to perform about 3000 requests per second with the same session, effectively reaching a 
CPU usage between 90% and 100% on all cores according to htop [12]. 

7 Discussion 

X-pire! has raised a huge discussion in Germany and received an overwhelming attention in the 
German media. Reports about X-pire! occurred in most of the major printed press, in major 
TV channels, and in the radio. The discussion on X-pire! mainly occurred in online media. 

Most of the criticism of X-pire! happened because people had wrong expectations and 
knowledge about the functionality of X-pire!. We provide our paper now to the public not only 
to provide in-depth information to all people interested in this approach, but also to clearly 
state once more what X-pire! can do, and what not. We believe that our approach is pretty 
close to what is achievable from a technical point of view. 

X-pire! is able to provide the following functionality: 

• Encryption of JPEG images and associating them with an expiration date. 

• Uploading these images to social networks such as Facebook or Flickr. 

• Viewing the images after the upload to a social network with our browser plug-in in 
supported browsers. 

• Captchas to increase the cost heavily for one attacker when collecting huge amounts of 
keys. 

What X-pire! is not intended to provide: 

• Does not prevent users from intentionally copying images after they got decrypted; this 
is always possible. 

• Users installing malware to collaboratively collect keys and store them on a third-party 
server whenever a picture is viewed; this is comparable to intentionally copying images 
that could also be stored unencrypted on another server. 

Especially the latter is suggested as a break of our system by [5]. However, we never claimed 
that X-pire! offers any form of protection against this kind of attacks. While this kind of attack 
could only be hardened, it can never be fully prevented as it constitutes the technical limit of 
what can be achieved. Further protection has to be provided e.g. by law enforcement. 

Related to the attack described above, some people have the opinion that the privacy im- 
provement through X-pire! is limited. Of course one would prefer if the aforementioned limi- 
tations would be avoided technically (which is not possible), but, even in the presence of these 
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limitations, X-pire! improves the user's privacy heavily. Without a huge amount of intention- 
ally bad users that collaboratively destroy the privacy of single users, this system provides a 
functional expiration date. This is clearly an improvement in comparison to one single attacker 
being able to simply write a crawler to collect all existing images. Only a huge bunch of either 
intentionally bad users or widely installed malware can collect keys or images efficiently. 

8 Conclusion and Future Work 

We have developed a novel, fast, and scalable system called X-pire! that allows users to set an 
expiration date for images in social networks (e.g., Facebook and Flickr) and on static websites, 
without requiring any form of additional interaction with these web pages. Once the expiration 
date is reached, the images become unavailable. A major technical challenge for rendering the 
approach possible for social networks ~ where by far the largest number of sensitive images are 
published - was to develop a novel technique for embedding encrypted information within JPEG 
files in a way that survives JPEG compression in real- world implementations. An additional 
feature of our approach is that the publishing user can dynamically prolong or shorten its 
expiration dates later, and even enforce instantaneous expiration. We have implemented our 
system and conducted performance measurements to demonstrate its efficiency. Our system 
can be applied to other data formats such as text messages as well, but we decided to focus 
on images first because of their distinguished importance for user privacy and their underlying 
technical challenges. Our current focus is to support additional social networks and other data 
formats in order to increase the usability of the approach. 
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A Further information on JPEG 

Figure [7] shows how single blocks are extracted from a single image. 
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Figure 7: JPEG block extraction 



Figure 8: Quantization table used by Face- 
book (luminance channel) 



After the block extraction, a quantization as described in Section [4] is applied. The quanti- 
zation table used by Facebook is shown in Figure [8} 
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CI "1 TVT J_ 1 

Social JNetwork 


max. Resolution 


Image Bytes 


Bytes 
incl. ECC 


Bytes 

w/o ECC 


Facebook 


720x720px 


468000 


117000 


87750 


Flickr 


1024xl024px 


976896 


244224 


183168 


wer-kennt-wen 


620x620px 


341000 


85250 


63937.5 



Table 1: Amount of bytes that can be embedded into the cover image 




Figure 9: Image uploaded using X-pire!; it has Figure 10: Image uploaded using only Face- 
the identical image quality as the Facebook im- book 
age on the right side 



B Image quality when using X-pire! 

Table [T] shows the maximum amount of bytes that can be embedded into the cover images for 
the aforementioned social networks. The maximum possible resolution is the maximum pixel 
size stored by the social network. All bigger pictures are resized to fit these limits. Besides the 
total amount of image bytes contained in our cover image, we provide the amount of bytes that 
can be embedded into it (including the error correcting codes) and the number of bytes that 
can be actually used for storing the image to be embedded. Since social networks store images 
only up to a specific resolution, the maximal file size accepted for embedding is the file size 
of the image to be embedded already after it has been resized and re-encoded to a resolution 
accepted by upload interfaces of social networks. Hence it is possible for example to provide a 
3500x2700px image that has a file size of 3.6MB to X-pire! and after scaling it to 720x720px 
and re-encoding it for Facebook it can still be embedded into a cover image. 

The images below show that the image quality remains unchanged when our method of 
uploading an image in a cover image is used. Figure d shows a 300x300px area of an image 



uploaded using our approach, whereas Figure 10 shows the same area of an image uploaded 
using only the Facebook interface. 
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